Loading ToolBench
MCP server for controlling Govee smart lights with LAN-first transport and cloud fallback
The server has 5 tools with reasonable descriptions and some parameter documentation, but exhibits several quality gaps typical of community servers. Tool names follow verb_noun convention (list_*, set_*) which is good. Descriptions are moderately detailed (80-150 chars, within the 10-1024 range) and explain what each tool does. However, schemas are incompletely documented: input parameters lack explicit type constraints (enums, ranges), and output schemas are entirely absent, callers cannot see what these tools return. Error handling is minimal (no recovery guidance, no actionable error messages visible in code). The LAN-first architecture is sophisticated but underdocumented in tool descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.
List all configured lights and their current state (online, power, brightness). State is read over LAN when the lamp is reachable locally, otherwise via the cloud.
Set a light's brightness (0–100%).
Set a light's RGB color. Accepts named colors (red, blue, …), hex (#FF0000), or r,g,b values.
Set a light's color temperature (2000–9000 K).
Turn a light on or off.
Output schemas completely undocumented. No tool specifies what fields are returned. LLMs cannot plan downstream calls or extract required data without seeing response structure.
Parameters lack enum constraints and validation ranges. 'power' accepts 'on' or 'off' but is documented as free-form string; 'brightness' lacks min/max; 'color' has complex implicit parsing rules (named colors, hex, r,g,b) not formalized in schema.
No tool annotations despite clear side-effect profile. set_power, set_brightness, set_color, set_color_temp are destructive (modify device state) but lack destructiveHint=true. list_lights is read-only but lacks readOnlyHint=true. Agents cannot reason about which calls are safe to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error handling is not visible in tool definitions and lacks recovery guidance. Code shows cloud fallback on LAN failure, but tool descriptions do not explain failure modes (light offline, network timeout, API rate limit) or suggest remediation (retry, try another light, check connectivity).
Parameter descriptions contain example values ('desk', 'bedroom', '#FF0000'). LLMs frequently reuse example values literally instead of adapting to user context, causing failed calls with the example light names.
'light' parameter accepts case-insensitive string without validation. No enum or list of available lights provided. If user says 'desk' but configured light is 'Desk' or 'desk_lamp', the tool may fail silently or find the wrong device. The description notes case-insensitivity but does not explain the matching algorithm.
Complex color parsing logic (named colors, hex, r,g,b) is not documented in the parameter constraint. Description reads like informal guidance ('Named color (blue, red, purple…), hex (#FF0000), or r,g,b (e.g., '255, 0, 0')') rather than a formal specification. Agents may pass invalid formats like 'rgb(255, 0, 0)' or 'blue_dark'.