weishaupt-wem-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEM_API_URL | No | API base URL (default: https://www.wemportal.com/app) | https://www.wemportal.com/app |
| WEM_PASSWORD | Yes | Your WEM Portal password | |
| WEM_USERNAME | Yes | Your WEM Portal email |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| wem_get_devicesA | Get all WEM devices with their modules. Returns device IDs, names, connection status, and module list (each with Index, Type, Name). Use this first to discover deviceId, moduleIndex, and moduleType needed for other tools. |
| wem_get_device_statusB | Get connection/online status of a specific device. |
| wem_get_parameter_metaA | Get metadata for all parameters of a module: parameter IDs, names, writable flag, data types, min/max values, enum options. Use this to discover available parameters before reading values. |
| wem_get_parametersA | Get all parameters of a module with current values. Combines metadata + refresh + read into one call. Returns parameter names, current numeric/string values, units, and writable flags. |
| wem_read_parametersA | Read current values for specific parameters. Refreshes data from device first, then reads. Use when you only need specific parameter values instead of all. |
| wem_get_overviewA | Get a complete overview of a device: all modules with all their parameters and current values in a single call. Useful for getting a full picture of the heating system state. |
| wem_get_writable_parametersA | Get only the writable parameters of a module (parameters that can be changed). Shows current values, min/max ranges, and enum options. Useful to see what can be adjusted. |
| wem_write_parameterA | Set a parameter value (e.g., target temperature). Only works for writable parameters. Check wem_get_parameter_meta for min/max values and enum options first. |
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 8 tools
Five of eight tools are read-oriented and overlap substantially: wem_get_parameters explicitly 'combines metadata + refresh + read', which duplicates wem_get_parameter_meta and wem_read_parameters, while wem_get_overview and wem_get_writable_parameters are largely views/filters over the same data. The descriptions do clarify scope (device-wide vs module-wide vs specific params vs writable-only), preventing total confusion, but an agent must read carefully to pick correctly.
All tools use a clean wem_<verb>_<noun> snake_case pattern. The only blemish is inconsistent verb choice for the same operation: wem_get_parameters vs wem_read_parameters vs wem_get_parameter_meta, which mixes 'get' and 'read' for parameter retrieval.
Eight tools is a reasonable, well-scoped size for a device-control server. However, the read surface (overview, all parameters, specific parameters, writable parameters, metadata) could likely be consolidated to 2-3 tools, so a couple of tools do not fully earn their place.
The lifecycle is well covered: device discovery, status, parameter metadata, reading values, and writing values form a complete read/inspect/write loop. Minor gaps remain: no batch write for multiple parameters, and no alarm/fault/error diagnostics beyond connection status.