Loading ToolBench
Official Yeelight IoT MCP server for device discovery, state, control, and scene execution
This server has critical definition quality issues. Tool names violate naming conventions (typo in 'get_currnet_house_info'), descriptions are in Chinese which makes them inaccessible to most English-speaking LLM agents, and schema documentation is minimal. While input schemas are present and parameters have types, the descriptions lack the actionable detail needed for LLM reasoning. The schema output structures are not documented. Error handling lacks recovery guidance. No tool annotations present. Composition is reasonable (8 distinct read/write tools) but execution paths are opaque.
工具用途：节点控制 - 家庭、区域、房间、设备组、设备都被视为"节点"，其类型通过 nodeType 区分。 - 节点控制请求中的 nodeId 是节点的唯一标识。用户通常提供的是节点名称，因此在调用控制接口前，必须先使用相应工具获取节点nodeId，nodeId可以是家庭ID，区域ID，房间ID，设备组ID，设备ID，确认后再执行控制操作。 - 节点控制指令通过 command 区分不同的操作。 - 控制指令中参数的 value 类型需与节点属性值的类型一致。 - 在调用此接口之前，请先确认节点支持的属性及其对应的可操作类型。如果目标节点不支持该属性，则无法进行控制。 - 控制指令中的propName（**参数名称propName请勿传错**）参数，必须填写节点属性列表中对应属性的 propId 字段值，如 p（开关）、c（颜色）、ct（色温）、l（亮度）、tp（窗帘开合度）等。应根据节点属性列表中支持的 propId 选择最合适的属性来进行控制操作。
工具用途：执行情景（场景、模式）。 - 在执行情景（场景、模式）前，必须确保已获取到对应的情景ID。由于用户通常提供的是情景名称，因此请务必先通过相应的工具获取情景ID，再使用该ID执行情景操作。 - 默认 dryRun=true，只返回执行计划，不调用真实执行接口。 - 如需真实执行，必须显式传 dryRun=false 且 confirmSideEffect=true。
获取当前用户家庭（项目）下所有的区域
获取用户当前家庭（或项目）的信息
获取当前用户家庭（项目）下所有的设备或者获取某个房间下的设备
获取当前用户家庭（项目）下所有的设备组或者获取某个房间下的设备组（设备组：相同设备类型的设备可以组成设备组，例如灯组、开关组灯）
Tool names contain typos and are not verb-noun consistent. 'get_currnet_house_info' has a spelling error ('currnet' vs 'current'). LLMs rely on exact tool names for invocation, typos cause tool selection failures.
All tool descriptions are in Chinese. This is a critical accessibility issue for English-speaking LLM agents (GPT-4, Claude, etc.). Descriptions should be in English to match the UI and API language. Non-English descriptions significantly reduce tool discoverability and adoption.
Descriptions lack actionable context. Examples: 'get_areas' has only Chinese text '获取当前用户家庭（项目）下所有的区域' without explaining when to call it, what it returns structurally, or how it chains with other tools. LLMs cannot infer intent, explicit context is required.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
获取当前用户家庭（项目）下所有的房间
获取当前用户家庭（项目）下所有的情景（场景、模式）
No output schemas documented. The server defines input schemas (e.g., 'get_devices' accepts context, roomId, cursor, limit) but does not specify what fields the response contains. LLMs cannot plan downstream calls or extract data without knowing the response structure.
Pagination pattern incomplete. Tools like 'get_devices', 'get_areas', 'get_groups', 'get_scenes' accept 'cursor' and 'limit' but no documentation specifies whether a 'total' count or 'nextCursor' is returned, making it impossible for LLMs to iterate safely over large result sets.
control_node and execute_scene require explicit dryRun=false and confirmSideEffect=true to execute. The descriptions mention this requirement in Chinese but provide no English actionable guidance on how LLMs should handle confirmation, what happens if confirmSideEffect=false, or what 'reason' parameter does in practice.
No error handling or recovery guidance documented. The tools provide no indication of what errors are possible (network failure, device offline, permission denied, invalid nodeId, etc.), how to classify them (retryable, user-fixable, fatal), or what the agent should do next.
No tool annotations present. Tools modifying state (control_node, execute_scene) should declare 'destructiveHint: true' and/or 'idempotentHint: false'. Readonly tools (get_*) should declare 'readOnlyHint: true'. MCP tool annotations enable clients to warn users before execution or suppress execution confirmation.
Parameter descriptions are minimal or missing. For example, control_node's 'controlRequest' parameter is documented only as 'node control request body' in English, but the nested properties (nodeId, nodeType, command) and their valid values are described only in Chinese comments within the propName field description.
Parameter constraints not explicit. For example, 'nodeType' is documented as accepting '1: room, 2: device, 3: area, 4: group, 5: home' but this is listed in a non-searchable comment in the description rather than as a proper JSON Schema enum. LLMs cannot reliably extract and enforce such constraints from prose.