Loading ToolBench
MCP server for OpenCCU-Loom, a daemon that bridges Homematic/HomematicIP CCU devices with Matter, MQTT, and provides REST/MCP APIs for device control, automation, and monitoring
OpenCCU-Loom MCP server demonstrates solid definition quality with 19 well-named tools following verb_noun conventions (list_*, get_*, read_*, arm_*, disarm_*, reset_*). All tools have descriptions (avg ~120 chars, within 10-1024 baseline). Input schemas are present and typed for all tools. However, parameter descriptions are sparse, many lack detail on format, constraints, or valid ranges. Output schemas are not documented. Error handling guidance is minimal. Tool composition is clean (single responsibility), but some tools could benefit from richer parameter constraints (enums for mode, zone_id). Risk annotations (READ_ONLY, WRITE) are present but not formalized as toolAnnotations in the MCP protocol.
Arm one alarm zone. Fails when a sensor blocks the arm — read list_alarm_zones and list_triggered_motion first. Zones whose policy requires a code cannot be armed from here.
Disarm one alarm zone. Zones whose policy requires a disarm code cannot be disarmed from here.
Fetch one device by address with its model, name, interface, and release status
Overall daemon health: component statuses and numeric gauges (latency, queue depth, etc.)
Read a data point's recorded measurement history, server-bucketed into evenly spaced points over a required time window (central, interface_id, channel, parameter, from, to are all required; there is no default window).
Overall Security & Safety state: the folded severity, the hazard classes that have known sources, and the standing faults.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. All 19 tools lack documented return types.
Parameter descriptions lack format/constraint details. E.g., 'mode' in arm_alarm_zone lists values (perimeter, full, night, vacation, custom) in description but should use enum constraint. 'limit' parameters lack min/max bounds. 'from'/'to' in get_measurements state RFC3339 but no validation guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
List every alarm zone with its arm state, active countdown and the number of latched motion detectors.
List operator-defined areas (room groupings one level above the CCU's flat room list) with their assigned rooms, optionally scoped to one central via central_name.
List the change log of configuration and data-point writes, newest first, scoped to the caller's role (admin only)
List the configured CCU names; pass one as central_name to scope other tools
List devices across one or all configured CCUs with their model, name, interface, and release status
List CCU heating groups (roster and members), one entry per central, optionally scoped to one central via central_name.
List the un-ignore patterns that promote otherwise-hidden parameters into the visible data-point surface, optionally scoped to one central via central_name.
List the daemon's incident log (health, connectivity, configuration errors), newest first, optionally scoped to one central
List the configured CCU interfaces with their connectivity state (connected, duty cycle, carrier sense). Read-only: reconnecting an interface actuates the radio link and is not exposed here.
List the motion detectors that are currently latched and can be cleared. A latched detector reads as open and can block arming.
Read a link's paramset (the configuration of a peer relationship between two channels)
Read a channel's MASTER (configuration) or VALUES (current state) paramset
Clear the latched motion detectors of one zone, or of every zone. Detectors that are not triggered are left alone.
No error handling guidance. Tools lack recovery hints (e.g., 'If zone not found, call list_alarm_zones first'). Destructive operations (arm_alarm_zone, disarm_alarm_zone, reset_motion) do not document failure modes or confirmation patterns.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not formalized in MCP protocol. Risk field (READ_ONLY, WRITE) is present in source but not exposed as MCP toolAnnotations capability.
Pagination not documented for list_* tools. list_devices, list_audit, list_incidents, list_groups, list_areas, list_hidden_parameters accept 'limit' but no 'offset'/'cursor' or 'total_count' in response. Large result sets risk context window exhaustion.