wattsonic-modbus-docs
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_registersA | Search the documented registers of the Wattsonic MATIC inverter (native EMS map and SunSpec map). Returns compact entries: address, name or SunSpec point, type, unit/scale or sf, access. Use get_register for the full record (value list, range, write function, effective conditions, read-back registers, persistence). Documentation only; never touches a device. |
| get_registerA | Full documentation of one register: name, description, type, scale/unit, access, documented range and values, and where documented: applies_from_firmware, write_function (0x06 only or 0x06/0x10), effective_when, confirm_by (registers to read back) and persistence (retained, volatile, volatile_over_tcp, command). For SunSpec addresses: model, point, size, sf with its constant value, writable range, device notes. Documentation only; never touches a device. |
| list_sunspec_modelsA | The device's SunSpec model chain: base address 40000 ('SunS'), each model with ID address, length, point count and writable points, the END marker, transport and data conventions (word order, scale factors, not-implemented values). Documentation only; never touches a device. |
| get_sunspec_pointB | One SunSpec point in the SunSpec model layout (name, type, size, sf, units, access, mandatory, symbols) with the device object: address, offset, implemented (yes/conditional/no), writable and write_range (raw), write_kind (control, stored_setting, fixed_value), sf_address and sf_value, and the device notes on how to read or write it precisely. Documentation only; never touches a device. |
| list_recipesA | List the closed-loop control recipes (id, title, interface, summary): EMS session with watchdog and heartbeat, active-power setpoint 11045, power limit 11320/11321, reactive power, Eco schedule, watchdog recovery, restart recovery, emergency stop, SunSpec gate, SunSpec active-power limit, SunSpec forced charge/discharge. Documentation only; never touches a device. |
| get_recipeB | A closed-loop control recipe: preconditions (with read checks), ordered steps (op read/write, address, function code, raw value or value range, check), confirmation reads with expected values, failure and recovery, notes and the documentation sections it is based on. Values are raw register values; negative values are sent as 16-bit two's complement. Documentation only; never touches a device. |
| validate_writeA | Check a planned write against the documentation WITHOUT writing anything: access (read-only points are rejected), documented range, scale, single-register requirement (0x06 only for 11300-11303, 11320-11324, 11330, 11057, 11254, commands), SunSpec writable range, gate and veto preconditions, side effects (e.g. 0x5A5A on 12026) and the registers to read back afterwards. Returns verdict ok / ok_with_warnings / reject with reasons. Guidance only; this server never connects to a device and never writes registers. |
| generate_client_codeA | Generate a client program template for a recipe, using the libraries of the website examples: Python pymodbus (ModbusTcpClient), Node.js modbus-serial, C# NModbus, Go goburrow/modbus. The template checks the preconditions, performs the write sequence with the documented function codes, reads the confirmation registers and runs the keep-alive. Conditional steps are behind flags that default to off. The code writes to a live inverter when run: review it first. This server only returns text and never connects to a device. |
| get_doc_sectionA | Return one section of the published documentation as Markdown (from the heading to the next heading of the same level). If the heading is not found, returns the list of section headings. Documentation only; never touches a device. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| integrate-matic-ems | Guide an EMS integration with a Wattsonic MATIC inverter step by step, precisely and closed-loop. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| native.md | Wattsonic MATIC Modbus documentation: native.md |
| sunspec.md | Wattsonic MATIC Modbus documentation: sunspec.md |
| llms.txt | Wattsonic MATIC Modbus documentation: llms.txt |
| registers.v1130.json | Wattsonic MATIC Modbus documentation: registers.v1130.json |
| sunspec-models.v1130.json | Wattsonic MATIC Modbus documentation: sunspec-models.v1130.json |
| recipes.v1130.json | Wattsonic MATIC Modbus documentation: recipes.v1130.json |
| VERSION.json | Wattsonic MATIC Modbus documentation: VERSION.json |
TDQS
Scored across 9 tools
Most tools have clearly distinct purposes: search vs full register lookup, SunSpec model vs point lookup, recipe list vs recipe detail, and validation vs code generation. The main possible confusion is between get_register and get_sunspec_point for SunSpec addresses, though their descriptions distinguish register-level and point-layout views.
All tools use snake_case with a predictable verb_noun pattern (search_registers, get_register, list_sunspec_models, get_sunspec_point, list_recipes, get_recipe, validate_write, generate_client_code, get_doc_section). The naming is internally consistent and readable.
Nine tools is well-scoped for a documentation/guidance server covering register lookup, SunSpec inspection, recipes, write validation, code generation, and documentation retrieval. Each tool appears to earn its place without excessive surface area.
The surface covers the main workflows: discovering registers, inspecting full records, navigating SunSpec models and points, listing and reading recipes, validating planned writes, generating client code, and retrieving documentation sections. Minor gaps exist, such as no dedicated recipe search/filtering or firmware-compatibility overview, but agents can likely work around them.