Matter Web Controller
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MATTER_SRV_KEY | Yes | API key for authentication. Required unless --insecure is used. |
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 |
|---|---|
| get_devicesA | List all devices (physical and logical) with their current states and aliases. |
| get_identitiesA | Hardware identity for every device: vendor, product/model name, node label, hardware/software versions, serial number, unique id, and Matter device-type ids. Physical Matter devices carry the full set (from Basic / Bridged Device Basic Information); logical devices report id + names only. Use to tell apart bridged children of one hub (e.g. Aqara sensors) that changed IDs after a re-pairing. If id is given, return just that one device — i.e. decode a dev_ id back to its node_id/endpoint_id + identity (the id is a one-way hash, so this is the way back). |
| get_lightsA | List lighting devices with normalized brightness (0.0-1.0) and color temperature (Kelvin). |
| get_sensorsA | List sensor devices with their metrics (illuminance, temperature, humidity, occupancy, etc.). |
| get_sensorA | Get a single sensor's data by device ID. |
| get_climateA | Read temperature (°C) and/or humidity (%) for every device that reports them
(Thermostat local_temperature + standalone temp/humidity sensors). If id is given,
return one device only. Each entry has |
| get_statusA | Quick summary: how many lights on/off, active sensors, connected bridges, total devices. |
| set_deviceC | Control a device. Brightness: 0.0 (off) to 1.0 (full). Temperature: Kelvin (e.g. 4000). |
| toggleB | Toggle a device on or off. If on, turns off. If off, turns on at full brightness. |
| set_levelA | Set raw brightness level (0-254) for a device. |
| set_miredA | Set color temperature in mireds for a device. |
| batch_controlA | Control multiple devices at once. Each action: {"id": "...", "brightness": 0.5, "temperature": 4000}. |
| set_nameB | Assign a display alias to a device. Aliases are for display only, not for ID resolution. |
| remove_nameC | Remove an alias from a device. |
| add_bridgeA | Register a remote logical bridge by IP and port. Optional api_key for authenticated peers (sent in the request body, never the URL). |
| remove_bridgeB | Remove a registered logical bridge. |
| register_deviceA | Commission a new Matter device using its pairing code (sent in the body, never the URL). Optionally specify IP and a name. |
| unregister_nodeA | Unpair a fabric node by node_id (clean up phantom/duplicate entries). |
| get_metadataB | Declarative bridge metadata (capabilities + states per device), as consumed by federation peers. HTTP-only on the REST side (/api/metadata). |
| list_acsA | List all ACs (Matter Thermostat endpoints) with on/off, system_mode, local temp, and setpoints in °C. |
| get_acA | Get a single AC's state by device ID. |
| set_acA | Control an AC.
|
| refreshA | Force refresh all device states from Matter bridge and logical bridges. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Some tools overlap in purpose: get_sensor/get_sensors/get_climate all report sensor-ish data, and set_device/set_level/set_mired/toggle/batch_control all control devices with slightly different parameters. Descriptions help but an agent could misselect between get_sensors and get_climate, or set_device versus set_level.
Most tools follow verb_noun with get_/set_ prefixes, but toggle, batch_control, refresh, and register_device/unregister_node deviate slightly (toggle lacks a noun, unregister_node uses 'node' vs 'device'). Overall pattern is discernible and consistent enough.
23 tools is at the high end for a controller but justified by diverse device types (lights, sensors, ACs, bridges). Still, it feels heavy; some tools could be consolidated (e.g., set_device overlapping with set_level/set_mired).
Covers core lifecycle: query (list, get, metadata), control (set, toggle, batch), naming, bridges, commissioning/unpairing, and refresh. Missing minor capabilities like updating device metadata or a generic get_device by ID, but agents can work around.