Growatt MCP Server

set_device_parameter

Destructive

Set a Virtual Power Plant (VPP) parameter on a Growatt device to adjust inverter settings like discharge cut-off SOC or time schedules, enabling remote control of solar installation behavior via the ShineServer API.

Instructions

Write a VPP (Virtual Power Plant) parameter on a device. Changes state on Growatt's side.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes	Parameter value. Time schedules take a JSON array such as [{"percentage":0,"startTime":120,"endTime":179}].
`plant_id`	No	Plant ID, as returned by get_plants. Empty means all plants.
`set_type`	Yes	VPP parameter name, e.g. "set_param_1" or "set_param_23" (discharge cut-off SOC).
`device_sn`	Yes	Device serial number.
`device_type`	Yes	Device type such as "min", "sph", "spa", "max", "inv", "wit", "tlx". get_devices returns it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 21, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare the tool as destructive and not read-only; the description's 'changes state on Growatt's side' adds a remote-side-effect note but little detail about reversibility, failure modes, or consequences of broad plant_id matching. It does not contradict the 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?

Two short sentences front-load the action and include a brief side-effect note. No filler or repetition.

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 schema and annotations carry the required parameter details and safety profile; output schema is present, so return values are not the description's burden. Missing when-to-use/alternative context is the main gap, but for a well-schema-covered tool the definition is otherwise complete.

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

Parameters3/5

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

Input schema covers 100% of parameters, including examples for set_type and value and the 'empty means all plants' behavior for plant_id. The description itself adds no parameter-level meaning, so it stays at the baseline.

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?

States a specific action—'Write a VPP parameter on a device'—and notes a state change on Growatt's side. The purpose is clear and distinct from read_device_parameter, but it does not explicitly distinguish itself from sibling setters like set_device_power or set_max_parameter.

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 this tool should be chosen over siblings such as read_device_parameter, set_device_power, set_max_parameter, or add_plant. The description does not mention prerequisites like get_devices/get_plants or state what types of parameter changes are appropriate.

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