Skip to main content
Glama
WattsonicAdmin

wattsonic-modbus-docs

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription
integrate-matic-emsGuide an EMS integration with a Wattsonic MATIC inverter step by step, precisely and closed-loop.

Resources

Contextual data attached and managed by the client

NameDescription
native.mdWattsonic MATIC Modbus documentation: native.md
sunspec.mdWattsonic MATIC Modbus documentation: sunspec.md
llms.txtWattsonic MATIC Modbus documentation: llms.txt
registers.v1130.jsonWattsonic MATIC Modbus documentation: registers.v1130.json
sunspec-models.v1130.jsonWattsonic MATIC Modbus documentation: sunspec-models.v1130.json
recipes.v1130.jsonWattsonic MATIC Modbus documentation: recipes.v1130.json
VERSION.jsonWattsonic MATIC Modbus documentation: VERSION.json

TDQS

A3.9/5.0

Scored across 9 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues