Loading ToolBench
This MCP server has significant definition quality issues. While 5 tools are present with Chinese descriptions, the descriptions are brief (averaging ~60 chars), many lack English translations despite being in an open-source JS project, and critical schema details are missing or incomplete. Parameters like 'siid', 'aiid', 'params' in do_action and get_property lack proper type documentation and constraints. No output schemas are visible in the code. Tool naming is reasonable (verb-based: notify, play_audio, set_volume, do_action, get_property) but parameter naming is inconsistent (did/siid/aiid are opaque system IDs without human-friendly alternatives). The risk annotations (WRITE/READ_ONLY) are present but error handling guidance is absent. Code inspection shows tool registration in mcp_server.js but schema definitions are not fully visible in the provided source.
向小爱音箱发送 MiOT 指令。
读取小爱音箱 MiOT 属性值。
向小爱音箱发送语音通知。适用于任务完成通知、提醒、警告等场景。音箱会用 TTS 播报传入的文字内容。
让小爱音箱播放指定的音频链接。
设置小爱音箱的音量。
Parameter descriptions missing for critical fields. 'siid' and 'aiid' in do_action and get_property are opaque system IDs with no guidance on how to obtain them or what range is valid. 'params' accepts 'any' type with no structure or validation constraints.
Descriptions are in Chinese only (avg 60 chars) and lack English equivalents. No non-trivial description guidance on WHEN to use each tool, WHAT data they return, or HOW to recover from failures. Descriptions do not state which tools are state-modifying vs read-only.
No output schemas documented. It is unclear what notify, play_audio, set_volume, do_action, and get_property return. LLMs cannot plan chained calls or extract relevant fields without knowing response structure. This violates the baseline (100% of A+ tools have documented return types).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Parameter 'did' (device ID) is exposed as a string without format constraints, human-readable name resolution, or validation. Users will not know valid DIDs. No enum or description of how to list available speakers.
No error handling guidance. Tools do not provide recovery hints (e.g., if a device is offline, suggest checking connectivity or listing available devices). Error responses are not designed to guide LLM retry logic or user correction.
Tool do_action combines multiple concerns: it requires the agent to know MiOT service IDs, action IDs, and parameter arrays. No abstraction or discovery tools to learn valid siid/aiid pairs. This forces users to consult external Xiaomi MiOT docs rather than querying the server.
Parameters 'volume' has min/max constraints (0-100) visible in schema but 'params' in do_action accepts 'any' type with no constraint. 'did' is optional but no clear indication of what 'default' behavior is if omitted.