What can you do with this server?

The GoodWe MCP Server allows you to monitor and control GoodWe solar inverters over a local network via the Model Context Protocol (MCP). Connection Management * Connect to an inverter by IP/hostname with optional port, family override, timeout, and retry configuration * Check connection status and retrieve device info (model name, serial number, firmware version) Live Monitoring * Read all runtime sensor data (PV production, battery state, grid import/export, load consumption), with optional filtering by sensor kind (PV, AC, BAT, GRID, UPS, BMS) * List all available sensors with their IDs and names * Read a single sensor by its ID (e.g., pv1_voltage, battery_soc, grid_power) Settings Management * Read all configurable settings and their current values, or read a single setting by ID * Write a new value to any configurable setting Operation Mode Control * Get the current operation mode and list of supported modes * Set the operation mode to: general, off_grid, backup, eco, peak_shaving, eco_charge, or eco_discharge (with optional eco power % and SOC % thresholds) Grid Export & Battery Control * Get and set the grid export power limit (0–10000 W; use 0 to disable export) * Get and set the battery depth-of-discharge (DoD) limit (0–99%) MCP Resources & Prompts * Access 7 MCP resources: inverter://status, inverter://runtime, inverter://settings, inverter://power/now, inverter://energy/today, inverter://battery, and inverter://sensors * Use 6 built-in prompt templates for status overviews, diagnostics, battery optimisation, grid export configuration, operation mode changes, and daily energy summaries Deployment & Security * Supports four transport modes: stdio, SSE, Streamable HTTP, and combined server * Bearer token authentication for HTTP transports * Flexible deployment via environment variables, Docker, Docker Compose, and Kubernetes

GoodWe MCP Server

by marcinn2

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

GoodWe Inverter MCP Server

MCP server for monitoring and controlling GoodWe solar inverters over the local network.

goodwe-inverter-mcp MCP server

Built on the goodwe library and the Model Context Protocol Python SDK.

Based on the Home Assistant GoodWe integration — the sensor definitions, operation modes, settings, and inverter family support are modelled directly after that implementation.

Features

Read live runtime data: PV production, battery state, grid import/export, load consumption
Read and write all configurable inverter settings
Switch operation modes (general, eco, backup, peak-shaving, off-grid, …)
Control grid export limit and battery depth-of-discharge
7 MCP resources: status, runtime, settings, power flow, daily energy, battery, sensor catalog
6 built-in prompt templates for common workflows (status overview, diagnostics, optimisation, …)
Bearer token authentication for all HTTP transports
Four transport modes: stdio, SSE, Streamable HTTP, and server (SSE + Streamable HTTP combined)
Auto-connect via environment variables

Related MCP server: Enapter MCP Server

Requirements

Python 3.10+
GoodWe inverter reachable on the local network (UDP port 8899 or Modbus/TCP port 502)

Installation

# with uv (recommended) — installs the locked dependency set from uv.lock
uv sync

# or a plain (editable) install
uv pip install -e .

Usage

stdio (Claude Desktop)

goodwe-mcp

Add to ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "goodwe": {
      "command": "goodwe-mcp",
      "env": {
        "GOODWE_HOST": "192.168.1.100"
      }
    }
  }
}

SSE transport

goodwe-mcp --transport sse --port 8080
# Server listens on http://0.0.0.0:8080/sse

Streamable HTTP transport

goodwe-mcp --transport streamable-http --port 8080
# Server listens on http://0.0.0.0:8080/mcp

Server transport (SSE + Streamable HTTP combined)

Serves both transports on a single port — useful when you need to support legacy SSE clients and modern Streamable HTTP clients simultaneously.

goodwe-mcp --transport server --host 0.0.0.0 --port 8080
# SSE:             http://0.0.0.0:8080/sse  (GET) and /messages/ (POST)
# Streamable HTTP: http://0.0.0.0:8080/mcp

Options

--transport {stdio,sse,streamable-http,server}   Transport mode (default: stdio)
--host HOST                                      Bind address for SSE/HTTP (default: 127.0.0.1)
--port PORT                                      Listen port for SSE/HTTP (default: 8000)
--log-level {DEBUG,INFO,WARNING,ERROR}           Logging verbosity (default: INFO)
--auth-token TOKEN                               Bearer token required on all HTTP requests (env: MCP_AUTH_TOKEN)
--base-url URL                                   Public base URL, e.g. https://mcp.example.com (env: MCP_BASE_URL)
--allowed-hosts HOSTS                            Comma-separated Host header values to accept (env: MCP_ALLOWED_HOSTS)
--allowed-origins ORIGINS                        Comma-separated Origin header values to accept (env: MCP_ALLOWED_ORIGINS)

Environment variables

Variable	Description	Default
`GOODWE_HOST`	Inverter IP / hostname for auto-connect on startup	—
`GOODWE_PORT`	Inverter UDP/TCP port	`8899`
`GOODWE_FAMILY`	Inverter family override (ET, EH, BT, BH, ES, EM, BP, DT, MS, NS, XS)	auto-detect
`MCP_AUTH_TOKEN`	Bearer token required on all HTTP requests	— (auth disabled)
`MCP_BASE_URL`	Public base URL of the server (used as OAuth issuer URL)	`http://<host>:<port>`
`MCP_ALLOWED_HOSTS`	Comma-separated `Host` header values to accept; enables DNS-rebinding protection on non-loopback binds	— (protection only on loopback binds)
`MCP_ALLOWED_ORIGINS`	Comma-separated `Origin` header values to accept (browser-based clients)	—
`MCP_PORT`	Listen port used by the container's default command and health check (Docker only)	`8000`

Authentication

Bearer token authentication is supported for all HTTP transports (sse, streamable-http, server). When enabled, every MCP request must include an Authorization: Bearer <token> header. The /health endpoint is always unprotected so Kubernetes probes continue to work.

Enable via environment variable (recommended)

export MCP_AUTH_TOKEN="$(openssl rand -hex 32)"
goodwe-mcp --transport server --host 0.0.0.0 --port 8080

Enable via CLI flag

goodwe-mcp --transport streamable-http --port 8080 --auth-token my-secret-token

Claude Desktop / MCP client configuration

Add the token to your client's MCP server configuration. For example, with Claude Desktop using the streamable-http transport via a proxy that injects the header, or with any client that supports Authorization headers:

{
  "mcpServers": {
    "goodwe": {
      "url": "http://localhost:8080/mcp",
      "headers": {
        "Authorization": "Bearer my-secret-token"
      }
    }
  }
}

Docker / Docker Compose

Pass the token through the environment:

MCP_AUTH_TOKEN=my-secret-token GOODWE_HOST=192.168.1.100 \
  docker compose -f docs/docker-compose.yml up -d

Kubernetes

Set the token in docs/k8s/secret.yaml before applying the manifests:

stringData:
  GOODWE_HOST: "192.168.1.100"
  MCP_AUTH_TOKEN: "my-secret-token"

If MCP_AUTH_TOKEN is empty or not set, authentication is disabled and all HTTP endpoints are publicly accessible. The server will log a warning at startup when bound to a non-loopback address without a token.

DNS rebinding protection

The MCP SDK validates the Host and Origin headers automatically when the server is bound to a loopback address. For any other bind address (including the Docker default 0.0.0.0), list the hostnames or host:port pairs that clients legitimately use to reach the server:

MCP_ALLOWED_HOSTS="mcp.example.com,192.168.1.10:8000" \
  goodwe-mcp --transport server --host 0.0.0.0 --port 8000

Requests whose Host header is not listed are rejected with HTTP 421. A :* suffix matches any port (e.g. 192.168.1.10:*). Use MCP_ALLOWED_ORIGINS to additionally allow browser-based clients from specific origins. The server logs a warning at startup when bound to a non-loopback address without this setting.

TLS / HTTPS

The MCP server itself does not terminate TLS. For any non-localhost deployment, place a TLS-terminating reverse proxy in front of it (nginx, Caddy, Traefik). Serving inverter data — which constitutes personal data under GDPR when linked to a household — over plain HTTP is a security risk.

Example with Caddy (simplest option):

mcp.example.com {
    reverse_proxy localhost:8000
}

Data Processing Notice

This server processes data from a GoodWe solar inverter, including the inverter's IP address, serial number, and energy consumption metrics. When deployed in a home and operated by the homeowner for personal use, this processing falls under the GDPR household exemption (Art. 2(2)(c)) and GDPR does not apply. If deployed commercially — for example to monitor inverters belonging to third-party customers — the operator becomes a data controller under GDPR (EU) 2016/679 and must establish a lawful basis for processing (Art. 6), maintain records of processing activities (Art. 30), and ensure appropriate technical and organisational measures (Art. 32), including TLS encryption and access control.

Docker

Build

Build for the current machine's architecture:

docker build -t goodwe-inverter-mcp:latest .

Multi-platform builds (amd64 + arm64)

Use docker buildx to produce an image that runs on both x86-64 servers and ARM boards (Raspberry Pi, Apple Silicon, AWS Graviton, etc.).

One-time setup — create a builder that supports cross-compilation:

docker buildx create --name multi --driver docker-container --bootstrap --use

Build both platforms and load into the local daemon — requires the containerd image store (enabled by default in Docker Desktop 4.34+; on Linux run dockerd --snapshotter=overlayfs or enable it in /etc/docker/daemon.json):

docker buildx build --platform linux/amd64,linux/arm64 -t goodwe-inverter-mcp:latest --load .

Build both platforms and push to a registry (e.g. Docker Hub or GHCR):

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t youruser/goodwe-inverter-mcp:latest \
  --push .

Build both platforms and export as a local OCI tar (no registry needed):

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t goodwe-inverter-mcp:latest \
  --output type=oci,dest=goodwe-inverter-mcp.tar .

Run

docker run -d \
  --name goodwe-mcp \
  -e GOODWE_HOST=192.168.1.100 \
  -p 8000:8000 \
  goodwe-inverter-mcp:latest

The container defaults to --transport server (SSE + Streamable HTTP on port 8000).

Change the port with MCP_PORT so the built-in health check follows it:

docker run -d -e GOODWE_HOST=192.168.1.100 -e MCP_PORT=9000 -p 9000:9000 \
  goodwe-inverter-mcp:latest

To change the transport, override the command. Keep MCP_PORT in sync, since the health check probes it:

docker run -d -e GOODWE_HOST=192.168.1.100 -e MCP_PORT=9000 -p 9000:9000 \
  goodwe-inverter-mcp:latest \
  goodwe-mcp --transport streamable-http --host 0.0.0.0 --port 9000

Docker Compose

GOODWE_HOST=192.168.1.100 docker compose -f docs/docker-compose.yml up -d

docs/docker-compose.yml uses network_mode: host by default so the container can reach the inverter on the local LAN. Remove that line if your network already routes LAN traffic into containers.

Kubernetes

Prerequisites

The GoodWe inverter communicates over UDP/TCP on the local network. The pod needs to reach the inverter's IP. The simplest setup is hostNetwork: true on a node in the same subnet; remove it if your cluster has flat networking or another routing solution.

Deploy

# 1. Edit the inverter IP
vi docs/k8s/secret.yaml

# 2. Apply all manifests
kubectl apply -f docs/k8s/

# 3. Check status
kubectl rollout status deployment/goodwe-mcp
kubectl logs -f deployment/goodwe-mcp

Health endpoints

Both liveness and readiness probes hit GET /health, which returns:

{ "status": "ok", "inverter_connected": true }

The pod becomes ready once the HTTP server is up. inverter_connected will be false until the server successfully connects to the inverter (auto-connect fires on the first MCP client session).

Tools

Tool	Description
`connect_inverter`	Connect to a GoodWe inverter by IP/host
`get_connection_status`	Check if connected and show device info
`get_device_info`	Model name, serial number, firmware version
`get_runtime_data`	All live sensor values (optional filter by kind: PV/AC/BAT/GRID/UPS/BMS)
`list_sensors`	List all sensor IDs and names
`read_sensor`	Read a single sensor by ID
`get_settings_data`	All configurable settings and current values
`read_setting`	Read a single setting by ID
`write_setting`	Write a value to a configurable setting
`get_operation_mode`	Current mode and supported modes
`set_operation_mode`	Set mode: general, eco, backup, off_grid, peak_shaving, eco_charge, eco_discharge
`get_grid_export_limit`	Grid export limit in watts
`set_grid_export_limit`	Set grid export limit (0 = disabled)
`get_battery_dod`	Battery depth-of-discharge setting
`set_battery_dod`	Set battery depth-of-discharge (0–99%)

Prompts

Pre-written prompt templates that MCP clients can fetch and use directly.

Prompt	Arguments	Description
`status_overview`	—	Full status report: connection, live power flow, battery, grid
`battery_optimisation`	—	Review battery settings and suggest DoD / mode improvements
`grid_export_config`	—	Check and adjust the grid export power limit
`operation_mode_change`	—	Explain available modes and help switch to the right one
`diagnose_issue`	`symptom` (optional)	Collect full diagnostics and identify problems
`daily_energy_summary`	—	Today's energy counters as a human-readable table

Resources

URI	Description
`inverter://status`	Connection status and device info (JSON)
`inverter://runtime`	All live sensor values (JSON)
`inverter://settings`	All configurable settings (JSON)
`inverter://power/now`	Real-time power flow — PV, battery, grid and load in watts, grouped by kind
`inverter://energy/today`	Today's energy counters — production, load, grid buy/sell, battery charge/discharge (kWh)
`inverter://battery`	Battery sensors, DoD limit and current operation mode in one payload
`inverter://sensors`	Static sensor catalog — id, name, unit and kind for every sensor (no live values)

Inverter families

Family	Models	Notes
ET / EH / BT / BH	Hybrid 3-phase	Battery support, up to 4 PV strings
ES / EM / BP	Hybrid single-phase	Battery support
DT / MS / NS / XS	Grid-tie only	No battery

Development

# install runtime + dev dependencies from the lockfile
uv sync

# run the test suite
uv run pytest

# with a coverage report
uv run pytest --cov=goodwe_mcp --cov-report=term-missing

# lint
uv run ruff check src tests

Tests run entirely against an in-memory fake inverter, so no hardware or network access is needed. They drive the server through a real MCP client session and the actual ASGI apps, covering tool input validation, resource payloads, bearer authentication, DNS-rebinding protection and the CLI. GitHub Actions runs the suite on Python 3.10 through 3.13 and builds the container image on every push and pull request.

License

See LICENSE file in the root of the repository.

Disclaimer

This software is not affiliated with or endorsed by GoodWe Inc. Use at your own risk. This software is a personal project that I maintain in my free time. Refer to the licence for more information.

Available Tools

15 tools

connect_inverterA

Connect to a GoodWe inverter over the local network.

Args: host: IP address or hostname of the inverter (e.g. "192.168.1.100"). port: UDP port — default 8899. Use 502 for Modbus/TCP. family: Optional inverter family override: ET, EH, BT, BH, ES, EM, BP, DT, MS, NS, XS. Leave blank for auto-detection. timeout: Per-attempt timeout in seconds. retries: Number of retry attempts on failure.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes
`port`	No
`family`	No
`timeout`	No
`retries`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral aspects. It explains parameters (host, port, family, timeout, retries) and mentions port alternatives and family auto-detection. However, it does not describe connection persistence, lifecycle, or error behavior, which is a gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with a purpose statement, followed by a clear Arg list. Each sentence adds necessary information without redundancy, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters with detailed semantics, but lacks information on connection state management (e.g., disconnection, multiple connections). Given the output schema likely handles return values, the description is mostly complete but could include a note on reconnection behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides comprehensive parameter details: host example, port default and alternative usage, family list with auto-detection note, timeout unit, and retries count. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Connect to a GoodWe inverter over the local network,' specifying the resource and context. It distinguishes from sibling tools that focus on data retrieval or setting, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as a prerequisite for other inverter tools but does not explicitly state when to use it or when not to. Including guidance such as 'Use this before reading sensor data' would enhance clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_battery_dodA

Get the battery depth-of-discharge setting (percentage of capacity that may be used).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the value as a percentage, but lacks details on authentication, performance, or side effects. With no annotations, the description provides minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema, the description sufficiently explains the setting's meaning. Could be improved by mentioning the return type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; baseline score of 4 applies. Description adds no parameter info, but none needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves the battery depth-of-discharge setting, distinguishing it from sibling set_battery_dod.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this vs alternative tools like set_battery_dod or get_grid_export_limit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_connection_statusB

Return the current connection status and basic device info.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden, but it only states the operation is a read without disclosing potential side effects, authentication needs, or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded, and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose, but given the existence of a sibling tool 'get_device_info' and no output schema details shown, there is ambiguity about overlap and completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100% implicitly. The description does not need to add parameter information, though it adds no extra value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns connection status and basic device info, but does not differentiate from the sibling tool 'get_device_info', which may overlap in scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives; the description simply states what it does without context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_device_infoA

Get model name, serial number and firmware version of the connected inverter.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It indicates a read operation by stating 'Get', but does not explicitly confirm safety, authentication needs, or potential failure modes. The simplicity of a parameterless tool partly mitigates this gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no superfluous words. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 an output schema exists, the description sufficiently states what is returned. However, it lacks usage context (when to call) and does not explain the return structure, though the output schema can fill that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100% (trivially). Baseline is 4 per rules. The description adds no parameter details, which is acceptable since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and specifies the resource: model name, serial number, firmware version of the connected inverter. It distinguishes from sibling tools like get_runtime_data or get_connection_status by focusing on device identity information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as get_connection_status or get_runtime_data. The description does not mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_grid_export_limitA

Get the current grid export power limit in watts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states what the tool does without disclosing side effects, permissions, or rate limits. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key information, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read operation; output schema exists so return details are covered. However, lacks usage context and behavioral depth given absent annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so baseline is 4. Description adds value by specifying the unit (watts), providing meaning beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the specific resource ('grid export power limit'), and distinguishes it from siblings like 'set_grid_export_limit'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., other read tools like get_runtime_data). No exclusions or conditions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_operation_modeA

Get the current operation mode and the list of modes supported by this inverter.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description is adequate for a simple read operation with no side effects, but does not disclose potential auth requirements or rate limits. For a zero-parameter read, it's minimally acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, clear, front-loaded with purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and existence of an output schema, the description adequately specifies what is returned (current mode and supported modes). Complete for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in input schema. Schema coverage is 100% (trivially). Baseline 4 for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get' and the resource 'current operation mode and list of supported modes'. Distinguishes from sibling 'set_operation_mode' by being a read operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance, but the purpose is clear and distinct from siblings. With sibling 'set_operation_mode', the usage is implied, but could be improved with a note like 'Use to read before writing'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_runtime_dataA

Read current live data from all inverter sensors.

Args: sensor_kind: Optional filter — one of PV, AC, UPS, BAT, GRID, BMS. Omit to return all sensors.

Returns power, voltage, current, energy, battery state, grid status and more.

ParametersJSON Schema

Name	Required	Description	Default
`sensor_kind`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It states the tool reads live data and lists return fields, which is adequate but doesn't disclose potential costs, caching, or side effects. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 lines), front-loaded with the main action, and includes parameter details efficiently. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is nearly complete. It explains what the tool does, the parameter, and return values. Minor omission: no mention of read-only nature, but it's clear from context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'sensor_kind' has 0% schema coverage, but the description adds clear semantics: optional filter with enumerated values and behavior when omitted. This fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read current live data from all inverter sensors', using a specific verb and resource. It distinguishes from siblings like 'read_sensor' by implying bulk read vs single sensor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions an optional filter and omitting to return all, but does not explicitly state when to use this tool vs alternatives like 'read_sensor' or 'list_sensors'. Usage context is implied but not definitive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_settings_dataA

Read all configurable inverter settings and their current values.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It states it's a read operation, which implies non-destructive, but lacks details on rate limits or return format (though output schema covers return).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single short sentence with no filler words. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema, the description adequately explains what the tool returns. Could mention that it returns all settings, but output schema covers structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so description does not need to add param info. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Read' and the resource 'all configurable inverter settings and their current values'. It distinguishes itself from siblings like read_setting which reads a single setting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 reading a single setting via read_setting, or any prerequisites like prior connection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sensorsA

List all sensor IDs and names available on the connected inverter.

Args: sensor_kind: Optional filter — one of PV, AC, UPS, BAT, GRID, BMS.

ParametersJSON Schema

Name	Required	Description	Default
`sensor_kind`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden; it states read-only operation but omits details like return format or pagination, though output schema covers return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences, first states purpose, second explains parameter; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with output schema; could mention default behavior (all sensors) but otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds significant value beyond schema by listing exact filter values (PV, AC, etc.) for sensor_kind, compensating for low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists sensor IDs and names from the connected inverter, which is distinct from sibling tools like read_sensor that read values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly clear for enumeration but lacks explicit guidance on when to use vs alternatives like read_sensor or get_runtime_data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_sensorA

Read the current value of a single sensor by its ID.

Args: sensor_id: Sensor identifier, e.g. "pv1_voltage", "battery_soc", "grid_power". Use list_sensors to discover available IDs.

ParametersJSON Schema

Name	Required	Description	Default
`sensor_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. The word 'Read' implies a non-destructive operation, but no additional traits (auth needs, rate limits, idempotency) are mentioned. While acceptable for a simple read tool, adding more context would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with only three sentences including the arg documentation. It front-loads the purpose and provides necessary guidance without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema, the description adequately explains the input and references list_sensors for discovery. It does not describe the output format, but given the existence of an output schema, this is acceptable. Could mention return type for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 provides concrete examples of sensor_id values ('pv1_voltage', 'battery_soc', 'grid_power') and instructs to use list_sensors for more IDs, adding significant meaning beyond the bare schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read the current value of a single sensor by its ID', using a specific verb (read) and resource (sensor value). It distinguishes itself from siblings by referencing list_sensors for ID discovery, which contrasts with other read tools like read_setting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to use list_sensors to discover available sensor IDs, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or compare to other get_* tools, which would be helpful but is not critical for a simple read operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_settingA

Read the current value of a single configurable setting.

Args: setting_id: Setting identifier. Use get_settings_data to see all IDs.

ParametersJSON Schema

Name	Required	Description	Default
`setting_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states it reads a value without discussing side effects, permissions, rate limits, or output format. The output schema exists but is not referenced. Behavioral details are minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with just two sentences, front-loading the purpose. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, the presence of an output schema, and sibling tools, the description is mostly complete. It tells the user how to find setting IDs, which is essential. Minor gap: does not describe the return value format, but output schema likely covers it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value beyond the input schema by explaining that setting_id is a 'Setting identifier' and pointing to get_settings_data for valid IDs. This compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads a single configurable setting, using the verb 'read' and specifying the resource. It distinguishes from siblings like get_settings_data (which lists all settings) and write_setting (which modifies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on how to obtain valid setting IDs via get_settings_data, which is helpful. However, it doesn't explicitly mention scenarios where alternative tools might be preferred, but for a single read, it's sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_battery_dodA

Set the battery depth-of-discharge limit.

Args: depth_percent: How much of the battery capacity may be discharged (0–99). Higher values allow deeper cycling but can reduce battery lifespan.

ParametersJSON Schema

Name	Required	Description	Default
`depth_percent`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that higher values reduce battery lifespan and defines the valid range. However, it omits whether the change is persistent, requires privileges, or affects ongoing operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with one sentence for purpose and a clear parameter explanation. No extraneous words, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter mutation tool with an output schema, the description covers purpose and parameter semantics. Minor missing details like success confirmation or error conditions, but sufficient overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only type and required, while the description explains the parameter's meaning (discharge percentage), range 0–99, and the trade-off between cycling depth and lifespan, adding significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set the battery depth-of-discharge limit' with a specific verb and resource. It distinguishes itself from sibling tools like get_battery_dod and other set tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when changing the DOD limit but lacks explicit guidance on when to use versus alternatives, prerequisites, or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_grid_export_limitA

Set the maximum power the inverter may export to the grid.

Args: limit_watts: Power limit in watts (0–10000). Use 0 to disable export.

ParametersJSON Schema

Name	Required	Description	Default
`limit_watts`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the valid range (0–10000) and that 0 disables export, but fails to mention whether the change is persistent, requires permissions, or what the response is. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus parameter detail, no wasted words. Information is front-loaded and efficiently communicated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple 1-parameter setter, but lacks details like confirmation of success, persistence, or side effects. The presence of an output schema (not shown) may mitigate, but the text remains minimal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter limit_watts lacks schema description (0% coverage). The user description adds essential semantics: 'Power limit in watts (0–10000). Use 0 to disable export.' This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Set the maximum power the inverter may export to the grid.' It specifies the verb (set) and resource (grid export limit), and distinguishes from the sibling get_grid_export_limit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adjusting the export limit, and the sibling tools provide context (e.g., get_grid_export_limit for reading). However, it lacks explicit guidance on when not to use or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_operation_modeB

Set the inverter operation mode.

Args: mode: One of: general, off_grid, backup, eco, peak_shaving, eco_charge, eco_discharge. eco_mode_power: Power level % for eco modes (0–100, default 100). eco_mode_soc: Battery SOC % threshold for eco modes (0–100, default 100).

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes
`eco_mode_power`	No
`eco_mode_soc`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose side effects, delays, or state changes beyond stating it sets the mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short, clearly formatted with header and bullet-style parameter list. Could use structured markdown but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers basic operation and parameters; lacks context on mode selection criteria. Output schema exists but is not in description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description adds critical info: lists allowed mode values, explains eco_mode_power/eco_mode_soc with defaults and ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the inverter operation mode, distinguishing it from siblings like get_operation_mode and other setter tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use specific modes or prerequisites; lacks context on inverter state requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_settingA

Write a new value to a configurable inverter setting.

Args: setting_id: Setting identifier. Use get_settings_data to see available IDs. value: New value as a string (converted to int/float automatically when possible).

Warning: Incorrect values can affect inverter operation. Verify the value before writing.

ParametersJSON Schema

Name	Required	Description	Default
`setting_id`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It reveals that the value is auto-converted to int/float when possible and warns about potential operational impact. It also references get_settings_data for valid IDs. This covers key aspects, though details on error handling or immediate effect are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear statement of purpose, parameter explanations, and a warning. The structure is logical, though the warning could be integrated more succinctly. It earns its sentences without excess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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, the description appropriately omits return value details. It covers the action, parameters, and a behavioral warning. Minor gaps like error behavior do not significantly impair completeness for a write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description provides rich parameter details: setting_id is explained with a reference to get_settings_data, and value is described with its auto-conversion behavior. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Write a new value') and the resource ('configurable inverter setting'). The sibling tools include read_setting and specific setters like set_battery_dod, so this generic write tool is well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when wanting to change a setting and includes a warning to verify values, but it does not explicitly state when not to use this tool or compare it to alternatives like set_battery_dod. The guidance is adequate but not thorough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

15 tool updatesv0.1.0Jun 22, 2026
- First observedconnect_inverter
- First observedget_battery_dod
- First observedget_connection_status
- First observedget_device_info
- First observedget_grid_export_limit
- First observedget_operation_mode
- First observedget_runtime_data
- First observedget_settings_data
- First observedlist_sensors
- First observedread_sensor
- First observedread_setting
- First observedset_battery_dod
- First observedset_grid_export_limit
- First observedset_operation_mode
- First observedwrite_setting

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-06-22 22:40 across 15 tools

Disambiguation5/5

Each tool has a clear, distinct purpose. Getters and setters are separated by domain (battery, grid, operation mode, settings, sensors), and there is no ambiguity between similar tools like read_sensor vs list_sensors or get_settings_data vs read_setting.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case. Verbs are uniform (connect, get, list, read, set, write) and nouns are specific, making the naming predictable and easy to understand.

Tool Count5/5

The server provides 15 tools, which is an appropriate number for a feature-rich inverter management server. Each tool serves a necessary function without redundancy, covering connection, monitoring, and configuration.

Completeness5/5

The tool set covers all essential operations for interacting with a GoodWe inverter: connection, device info, live data, settings retrieval and modification, and key parameter adjustments (battery DoD, grid export limit, operation mode). There are no obvious gaps for standard remote management tasks.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-teslaOAuth
io.github.jlestel
MCP server wrapping the Tesla Fleet API and TeslaMate API
Energy Home Automation & IoT App Automation
23
Home Automation Mcp D
io.github.varvararatta
MCP server for Home Automation
Home Automation & IoT
2
remote-mcp-serverOAuth
io.coupler
Coupler.io remote MCP server
Data Platforms App Automation Developer Tools
2
hostinger-api-mcpOAuth
io.github.hostinger
MCP server for Hostinger API
Cloud Platforms Developer Tools
1151

Related MCP Servers

MCP Energy Server
Government Data Open Data Research & Data
ebarros23
A
license
Not graded
quality
Not graded
maintenance
Provides access to comprehensive U.S. and international energy data from the EIA API, including electricity, natural gas, petroleum, coal, renewables, CO2 emissions, and energy forecasts.
Updated 10 months ago (2025-11-10 12:40 UTC)
MIT
Enapter MCP Serverofficial
Energy Monitoring Cloud Platforms
Enapter
A
license
Not graded
quality
B
maintenance
MCP server providing tools for AI-agents to interact with Enapter EMS.
Updated 2 months ago (2026-07-16 18:02 UTC)
Apache 2.0
Victron VRM MCP Server
Energy Monitoring
gimi-q
A
license
B
quality
D
maintenance
Read-only MCP server integrating with the Victron VRM API to monitor solar systems, batteries, alarms, and more.
Updated a year ago (2025-08-20 22:29 UTC)
41
7 npm
6
MIT
Solplanet MCP
Energy Home Automation & IoT
kalmma
A
license
Not graded
quality
C
maintenance
MCP server for Solplanet ASW5-T inverter, enabling natural language queries about solar energy system status and control.
Updated 18 days ago (2026-08-27 08:29 UTC)
MIT

GoodWe Inverter MCP Server

Features

Requirements

Installation

Usage

stdio (Claude Desktop)

SSE transport

Streamable HTTP transport

Server transport (SSE + Streamable HTTP combined)

Options

Environment variables

Authentication

Enable via environment variable (recommended)

Enable via CLI flag

Claude Desktop / MCP client configuration

Docker / Docker Compose

Kubernetes

DNS rebinding protection

TLS / HTTPS

Data Processing Notice

Docker

Build

Multi-platform builds (amd64 + arm64)

Run

Docker Compose

Kubernetes

Prerequisites

Deploy

Health endpoints

Tools

Prompts

Resources

Inverter families

Development

License

Disclaimer

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Enapter MCP Serverofficial