Loading ToolBench
A Model Context Protocol server for interacting with HomeyPro home automation systems. Provides paginated access to devices, zones, and flows with comprehensive management capabilities.
HomeyPro MCP provides comprehensive tool coverage (19 tools) with generally good naming conventions (verb_noun pattern) and consistent descriptions. However, there are significant gaps: output schemas are not documented in the provided code, parameter descriptions are minimal or absent for many tools, and error handling guidance is not visible. The 'compact' parameter appears across 12 tools with identical semantics but no clear guidance on what fields are excluded when true. Tool names are clear and action-oriented, but downstream field naming consistency (critical for tool chaining) cannot be verified without seeing actual response structures. Parameter validation rules and constraints are underdocumented, e.g., search queries, device_ids, and capability_ids lack format/length guidance.
Control a device by setting capability values.
Get detailed information about a specific device.
Get insights data for a specific device (energy consumption, etc.).
List all possible device capabilities, useful for getting to know what to look for. Usually better to query it before searching by name first
List all possible device classes, useful for getting to know what to look for. Usually better to query it before searching by name first
Get all flow folders.
Output schemas not documented. No visibility into return types, required fields, or response structure for any tool. LLMs cannot infer what fields to expect or plan downstream tool calls (e.g., what fields does list_devices return? Is 'id' or 'device_id' used?). This violates pattern:tool and mxe:include-chaining-ids.
Parameter 'value' in control_device lacks type, description, and format constraints. The schema shows no type for the 'value' field, making it impossible for LLMs to determine what to pass. Should specify: type (string|number|boolean), constraints (e.g., 0-255 for brightness), and examples ('on', 45, false). Violates pattern:constrained-input and pattern:tool-description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get all flows within a specific folder with pagination support.
Get all flows that are not assigned to any folder with pagination support.
Get performance and usage metrics for the HomeyPro MCP Server.
Get system information from HomeyPro.
Get all devices within a specific zone with pagination support.
Get the average temperature in a specific zone.
Perform a health check of the HomeyPro MCP Server. This tool checks connectivity to HomeyPro, response times, and basic system functionality. Useful for monitoring and diagnostics.
List all devices with pagination support.
List all flows (both normal and advanced) with pagination support. This consolidated function retrieves both normal and advanced flows in a single call, combining them into a unified response. Each flow includes a "flow_type" field indicating whether it is a "normal" or "advanced" flow.
List all zones with pagination support.
Search devices by class with pagination support.
Search devices by name with pagination support. Using note field from the result could be helpful too.
Trigger a flow (normal or advanced) by its ID.
Pagination parameters ('cursor', 'compact') are repeated across 12 tools but lack consistency guidance. The description 'Optional cursor for pagination. If not provided, starts from the beginning.' does not explain: what format is a cursor? Is it opaque? Is it page-based or token-based? What does 'compact' exclude exactly? Violates pattern:paginated-result.
No error handling guidance visible. No documentation of what errors can be returned, how LLMs should respond (retry vs ask user vs fatal), or what to do next. For example: control_device can fail if the device is offline or capability is unsupported, LLM needs guidance (e.g., 'Device offline, try again in 30s' vs 'Unsupported capability, check get_devices_capabilities'). Violates pattern:recovery-guide and pattern:error-classification.
control_device (WRITE operation) lacks confirmation/dry-run support. Agents can trigger device actions without reversibility. Should offer a 'preview' or 'confirm' mode to prevent accidental state changes. Violates pattern:confirmation-request.
Tool chaining broken by field naming uncertainty. If list_devices returns 'id' but control_device expects 'device_id', the LLM must infer or discover the mapping. The tooling does not document what IDs are returned by read tools or what names are expected by write/action tools. Violates mxe:response-field-naming.
Parameter descriptions are too generic or missing. Examples: 'device_class' description is 'Device class to search for (e.g., "light", "thermostat").', but LLMs need: Are there other valid values? Can I call get_devices_classes first to see the full list? Is the match case-sensitive? Are substring matches allowed? Violates pattern:tool-description.
No documentation of required discovery flow. The tools suggest 'Usually better to query it before searching by name first' for get_devices_classes, but this is not mandatory guidance. LLMs should understand: Do I need to call get_devices_classes before search_devices_by_class? Or is class name sufficient? Are there dependencies between tools?