MCP server for Homey Pro smart home control
Strong tool naming (verb_noun pattern consistently applied across all 11 tools). Descriptions are detailed and actionable (avg ~180 chars), exceeding the 10-1024 char baseline. All parameters have type definitions and descriptions. Input schemas use Zod with proper typing. However, output schemas are not formally documented, responses are JSON-formatted but lack explicit schema declarations. Error handling is basic (returns isError flag with text message, but lacks recovery guidance or error categorization). Tool annotations present (readOnlyHint, destructiveHint, idempotentHint) align with current spec. No pagination support on list_* tools despite potentially large result sets.
Get detailed information about a specific device by ID, including all capability values, settings, and availability status. Use list_devices or search_devices first to find the device ID.
List all installed Homey apps with version, enabled status, and origin (appstore or devkit). Apps provide device drivers, flow cards, and integrations.
List all Homey devices with current capability values. Returns device ID, name, class, zone, availability, capabilities, and live sensor/state values. Use 'zone' to filter by room name (partial match) or 'class' to filter by device type (light, sensor, thermostat, speaker, lock, socket, etc).
List all automation flows (simple and advanced). Returns flow ID, name, enabled/broken status, and type. Flows are Homey's automations with WHEN/AND/THEN logic.
List all logic variables with their current values. Logic variables store state (boolean, number, string) that can be used in flow conditions and actions.
Output schemas not formally documented. Responses are JSON-formatted but lack explicit schema declarations in tool definitions. LLMs cannot reliably predict response structure for downstream planning.
No pagination support on list_* tools. list_devices, list_zones, list_flows, list_variables, list_apps lack limit/offset or cursor parameters. Large result sets risk context window exhaustion.
Error handling lacks recovery guidance and categorization. Errors return isError flag with text message but do not indicate whether failure is retryable, user-fixable, or fatal. No suggestions for next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List all zones (rooms/areas) in the home with their hierarchy. Returns zone ID, name, parent zone, and icon. Zones are organized in a tree: Home → Floors → Rooms.
Search devices by name, device class, or capability name. Returns matching devices with their current values. Useful for finding devices when you don't know the exact ID — e.g. search 'temperature' to find all temperature sensors, or 'kitchen' to find devices with kitchen in the name.
Control a device by setting a capability value. Common capabilities: 'onoff' (boolean — turn on/off), 'dim' (number 0-1 — brightness), 'target_temperature' (number — thermostat setpoint), 'volume_set' (number 0-1). Use get_device first to see available capabilities and their current values.
Enable or disable a flow automation. Disabled flows won't trigger. Use list_flows to find the flow ID.
Set the value of a logic variable. The value type must match the variable type (boolean, number, or string).
Trigger (run) a flow immediately by its ID. Tries simple flow first, then advanced flow. Use list_flows to find the flow ID.
set_device_capability accepts union type (boolean|number|string) without validation. No guidance on which capability types accept which value types. LLMs may pass invalid types.
Homey API credentials injected via environment (getHomeyApi() call), but no explicit documentation of required env vars or secret injection pattern in tool descriptions.