Loading ToolBench
MCP server to control an LG ThinQ washing machine via the ThinQ Connect API
Server exposes 5 well-named tools with clear, domain-specific descriptions (avg 180 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are undocumented (tools return JSON strings, not structured objects), and error handling lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Naming follows verb_noun pattern well (list_devices, get_washer_profile, control_washer). Parameter descriptions are adequate but could specify constraints more formally (e.g., operation enum values, location format). Missing pagination for list_devices despite potential for multiple devices.
Start, stop, power off, or wake the washer. `operation` must be one of: START, STOP, POWER_OFF, WAKE_UP. `location` is the device zone from the profile (default "MAIN"). Location-scoped washers reject commands that omit it (API error code 2207). Note: most LG washers only accept a remote START when the machine has been physically set to "Remote Start" and a cycle is already selected/loaded. The API pauses/resumes or starts a pre-selected cycle; it generally cannot pick a wash program from scratch. Call get_washer_profile first to confirm the model supports the operation and to see the exact accepted values.
Escape hatch: send an arbitrary control payload to the washer. `control_json` is a JSON object matching the shape shown in the device profile, e.g. {"operation": {"washerOperationMode": "START"}}. Use this for model-specific properties (timers, remote-control toggles, etc.) that the higher-level tools do not cover.
Get a washer's capability profile: the exact controllable properties and their allowed values for THIS specific model. Consult this before controlling, because property names/values vary by model.
Get the washer's current live state: whether it is running, the current cycle/run state, and remaining time.
Output schemas undocumented. All tools return JSON strings via _dump(), but LLMs cannot infer field structure. Responses should document expected fields (deviceId, status, remainingTime, etc.) so agents can extract and chain data.
Missing tool annotations. control_washer and control_washer_raw are destructive (WRITE risk) but lack destructiveHint annotation. get_washer_* tools are READ_ONLY but lack readOnlyHint. Annotations guide agent planning and safety.
Error handling lacks recovery guidance. ThinQError exceptions return bare 'ThinQ API error: {e}' strings. Should categorize errors (retryable vs user-fixable), suggest next steps (e.g., 'Check device_id with list_devices()'), and include invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List all LG ThinQ devices on the account. Use this to find the washer's deviceId, which every other tool needs.
Parameter 'operation' in control_washer lacks enum constraint. Description lists allowed values (START, STOP, POWER_OFF, WAKE_UP) as text, but schema has no enum field. LLMs may hallucinate invalid values; formal enum prevents this.
list_devices lacks pagination. If account has many devices, response could be large. Should accept limit/offset params and return total count or next_cursor, per pattern:paginated-result.