Loading ToolBench
Control your AC through SwitchBot Hub 2 using MCP. Provides tools for AC control, status monitoring, device discovery, and automated scheduling with AI decision-making.
This server has 12 tools with reasonable naming conventions and basic schema definitions, but falls short of production quality due to incomplete descriptions, missing parameter details, and inadequate error handling guidance. Naming follows verb_noun patterns (turn_ac_on, set_ac_temperature, get_ac_status), which is good. However, descriptions are generic and lack the context LLMs need for selection and chaining. Parameter descriptions exist but many lack format/range guidance. Output schemas are not documented anywhere in the provided code. Error handling is minimal, there's no guidance on retry semantics, user-fixable vs fatal errors, or recovery steps.
Check if SwitchBot credentials are configured and valid.
List all infrared devices (to find your AC device ID).
Get current AC status (power, temp, mode, fan).
Get room temperature and humidity from Hub 2.
List common AC commands for send_custom_ac_command.
Send custom command (swing, turbo, sleep, etc.).
Output schemas completely undocumented. Tools like get_ac_status, get_room_temperature, get_ac_devices, and list_common_ac_commands have zero documentation of return types or fields. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect.
Parameter descriptions lack actionable constraints. Many parameters (temperature, mode, fan_speed) have descriptions but omit crucial details like 'what happens if AC is off?', 'can this be changed while AC is running?', 'what are the precedence rules if multiple settings conflict?'. set_ac_temperature says 'AC must be on' in the description but this should be enforced with explicit error handling, not just documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Set all AC settings at once.
Change AC fan speed (AC must be on).
Change AC mode (AC must be on).
Change AC temperature (AC must be on).
Turn off the AC.
Turn on the AC with specified settings.
Tool descriptions are generic and do not guide selection or explain when to use one tool vs another. 'Turn on the AC with specified settings' vs 'Set all AC settings at once', what's the difference? When should an agent choose turn_ac_on vs set_ac_all_settings? Descriptions fail to answer this.
send_custom_ac_command accepts free-form command strings without validation or enumeration. The parameter description mentions 'swing, swingHorizontal, timer, sleep, turbo, economy, quiet, light, turnOn, turnOff, setAll' but these are not declared as an enum. LLMs will hallucinate invalid command names.
No error handling guidance for any tool. What happens if credentials are invalid? If the AC device is unreachable? If a temperature value is out of range? Tools must return actionable recovery steps (e.g., 'User not found. Try search_users() with a partial name.'), not silent failures.
Idempotency and state management unclear. Is turn_ac_on idempotent if the AC is already on? Can set_ac_temperature be safely retried if network fails mid-request? These answers are critical for agent reliability but not documented.