Hubitat MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HUBITAT_HOST | Yes | Hub IP/hostname | |
| HUBITAT_APP_ID | Yes | Maker API app ID | |
| HUBITAT_ACCESS_TOKEN | Yes | Maker API token | |
| HUBITAT_DEVICE_STORE | No | polling or cached (eventsocket) | polling |
| HUBITAT_ENABLE_ADMIN | No | Register admin tools | false |
| HUBITAT_POLL_CACHE_TTL_MS | No | Soft TTL for polling store (0 = always fresh) | 0 |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hubitat_list_devicesA | List devices authorized in Maker API. Returns id, name, label, room, and capabilities summary. Use when: discovering devices or finding an ID before send_command. Do NOT use when: you already know the device ID (use hubitat_get_device). Note: Rule Machine rules cannot be listed — only devices Maker API can see. |
| hubitat_get_deviceA | Get a single device's details and current attributes from Maker API. Use when: you need current state (switch, level, battery, etc.). Do NOT use when: you only need the list of IDs (use hubitat_list_devices). |
| hubitat_get_device_commandsA | List commands available for a device via Maker API. Prefer this over guessing command names. Use when: before hubitat_send_command to confirm the command exists. Do NOT use when: sending a known simple Switch on/off. |
| hubitat_send_commandA | Send a generic Maker API command to a device: /devices/{id}/{command}[/{value}]. Use when: turning devices on/off, setLevel, lock, etc. Do NOT use when: setting color from hex — use hubitat_set_color instead. Validates the command exists via /commands before sending. |
| hubitat_set_colorA | Set a ColorControl device color from a hex string. Builds the URL-encoded JSON map Maker API expects (including Hubitat's hex extension). Nobody constructs this by hand correctly. Use when: setting bulb color from #RRGGBB or RRGGBB. Do NOT use when: only changing level or on/off. |
| hubitat_list_virtual_devicesA | List devices that look like virtual switches/buttons (Rule Machine levers). Rule Machine has no API — flip a virtual switch or set a hub variable to trigger rules. Use when: finding a virtual switch to drive Rule Machine. Do NOT use when: controlling physical devices (use hubitat_list_devices). |
| hubitat_get_hub_variableA | Read a Hubitat hub variable (admin route; firmware-sensitive). Hub variables are one of two Rule Machine levers (with virtual switches). Use when: reading a variable that rules subscribe to. Do NOT use when: controlling a device attribute (use hubitat_get_device). |
| hubitat_set_hub_variableA | Write a Hubitat hub variable (admin route; firmware-sensitive). Triggers Rule Machine subscriptions on that variable. Use when: automating Rule Machine without a virtual switch. Do NOT use when: sending a device command (use hubitat_send_command). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| capabilities | Static capability → common commands map. Prefer hubitat_get_device_commands for per-device truth. Rule Machine has no API — use virtual switches or hub variables. |
TDQS
Scored across 8 tools
Every tool targets a distinct resource (hub variable vs device) and action (list/get/send/set), and the descriptions explicitly provide 'Do NOT use when' guidance to steer agents away from wrong choices. The get vs list vs send tools are clearly separated by their 'Use when'/'Do NOT use when' annotations, leaving no realistic ambiguity.
The naming follows a consistent hubitat_verb_noun pattern (hubitat_list_devices, hubitat_get_device, hubitat_send_command). Minor deviations: 'hubitat_list_virtual_devices' reads more as an adjective-modifier than a pure noun, and set_color/send_command/hub_variable all mix nouns, but the pattern is mostly uniform with one verb-noun structure throughout.
8 tools is a well-scoped count for a home-automation hub server. Each pair (list/get, get/send, get_device_commands/send_command, list/get hub_variable) earns its place, and the set covers discovery, control, color, and rule-machine levers without bloat.
The surface covers device discovery, state querying, command listing, generic command sending, and color setting, plus virtual-switch and hub-variable rule triggers. Minor gaps: there's no tool for device detail beyond get_device or updating device config, but the core workflows (discover, query, control, trigger) are all covered with no dead-end operations.