Wyzer MCP Server
Server 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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesB | List all discovered Wyze devices with their current status. Optionally filter by device type. |
| control_plugC | Turn a Wyze plug on or off. Use device ID or nickname to identify the plug. |
| control_switchB | Turn a Wyze wall switch on or off. Use device ID or nickname to identify the switch. |
| control_thermostatA | Control a Wyze thermostat. For combined thermostat+plug devices, "turn_on"/"turn_off" controls the plug (heater power). Temperature actions control the thermostat. |
| control_purifierB | Control a Wyze air purifier. Set power state (on/off) and/or fan mode. Use device ID or nickname to identify the purifier. |
| get_device_statusA | Get detailed status of any Wyze device. Returns temperature, humidity, setpoints for thermostats; on/off state for plugs and switches; AQI and fan mode for air purifiers. |
| get_api_statusA | Get Wyze API rate limit status and key expiration. Returns remaining calls, reset time, cache info, and API key expiration. |
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 7 tools
Most tools are clearly distinct per device type (purifier, plug, switch, thermostat), and control_* vs get_device_status vs list_devices are well-separated. Minor potential confusion between control_plug and control_switch, and the special combined thermostat+plug behavior in control_thermostat could be overlooked, but descriptions mitigate this.
The control_* verb-noun pattern is used consistently for four device actions, and list_devices/get_device_status/get_api_status follow a verb_noun get_/list_ pattern. Minor deviation: control_thermostat spans two devices, and the get_/list_ mix is slight, but overall the schema is predictable and readable.
Seven tools is an appropriate, well-scoped surface for a home IoT control server covering discovery, per-device control, status retrieval, and API health—all within the ideal 3-15 tool range with no redundancy.
The surface covers discovery, status, and control for four device types, plus API health—a solid set. Minor gaps include no bulk control, no scheduling, and no device registration/removal, but core lifecycle (list, get status, control) is fully covered and agents won't dead-end.