Loading ToolBench
Model Context Protocol server for Fibaro Home Center 2 integration with AI assistants
This server has 24 tools with basic structure but significant quality gaps. Naming is clear and verb-driven (list_, get_, control_, trigger_), which is good. However, most tools lack output schemas, parameter descriptions are sparse or missing, and error handling guidance is absent. Only 2 of 24 tools have output schemas defined (get_icons, get_consumption). Most tools have empty or minimal parameter descriptions. The server does not implement any current MCP patterns for error recovery, confirmation requests, or idempotent hints. While the tool set is well-organized by domain (devices, rooms, scenes, system), the execution quality is below production baseline.
Control a device (turn on/off, set value, etc.)
Return capability summary for a deviceId to help agents decide actions
Get consumption reports/data
Get detailed information about a specific device
Get system diagnostics from Fibaro system
Get energy consumption for rooms or devices
Get list of available icons from Fibaro
22 of 24 tools lack output schemas. Only get_icons and get_consumption define outputSchema. LLMs cannot know what fields to expect in responses, forcing them to guess at downstream field names for tool chaining. This violates the 'Document the output schema' critical check.
Parameter descriptions are minimal or missing across all tools. Examples: 'device_id' in get_device has only 'The device ID' (9 chars, below 20-char threshold); 'action' in control_device lacks guidance on valid values; 'args' in control_device says 'Optional arguments for the action' but does not explain format or examples. This violates 'Every parameter needs a description explaining what it controls.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 24 | 2024-11-05+ | v1 |
Get iOS devices registered in the system
Get location information from Fibaro system
Get RGB lighting programs
Get detailed information about a specific room
Get all devices in a specific room
Get detailed information about a specific scene
Get a specific section by ID
Get Fibaro Home Center system information
Get tracking schedules
Get a specific user by ID
Get weather information from Fibaro system
List all devices in the Fibaro Home Center system
List all rooms in the Fibaro Home Center system
List all scenes in the Fibaro Home Center system
List all sections in Fibaro system
List all users in Fibaro system
Trigger/execute a scene
control_device tool (WRITE operation) lacks error handling guidance and confirmation/dry-run pattern. Description does not state that this is a destructive operation or warn about side effects. Per 'Irreversible operations should support a dry-run or confirmation step', destructive tools should offer safeguards.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. The server marks tools with Risk: READ_ONLY and Risk: WRITE in metadata but does not implement the current MCP tool annotation pattern. This prevents clients from applying safety policies or confirming destructive actions.
control_device 'action' parameter has no enum constraints. LLMs will hallucinate action values. Should declare action as enum with explicit allowed values.
No pagination support documented. Tools like list_devices, list_rooms, list_scenes, list_users, list_sections will return all items without limit or cursor. Per 'Tools returning lists should accept page/offset and limit parameters', large result sets will blow context windows and the server offers no guidance on managing this.
No error recovery guidance in any tool. Tools lack descriptions of error cases, conditions that cause failures, or recovery steps. Per pattern:recovery-guide, error responses must tell the LLM what to do next. Current design offers no such path.
Parameters like 'device_id', 'room_id', 'scene_id', 'user_id', 'section_id' require numeric IDs. Per 'Accept human-friendly identifiers (email, username) alongside system IDs', tools should support name-based lookups (e.g., device_name, room_name) to match chat interactions. Currently agents must know or lookup IDs first.