MCP server for smart home device control with support for lights, thermostats, door locks, and scene activation
The Home Automation MCP server provides 5 clearly named tools with consistent verb-noun patterns (list_devices, control_light, set_temperature, control_door_lock, activate_scene). All tools have descriptions and visible JSON schemas with typed parameters and enums for constrained inputs. However, definitions fall short of production grade in several areas: parameter descriptions lack constraint details (ranges, formats), output schemas are not formally documented, error handling is minimal with no recovery guidance, and there are no per-tool security annotations despite write operations on sensitive devices (door locks, thermostats). The descriptions are concise but under-optimized for LLM decision-making, they state WHAT the tool does but lack WHEN/WHY context. Average parameter annotation length is ~40 chars, below the baseline of 72. Tool composition is sound (each tool has one responsibility) but no idempotency or dry-run mechanisms for irreversible operations.
Activate a preset scene that controls multiple devices
Lock or unlock the front door
Control the living room light (on/off/toggle) and optionally set brightness (0-100)
List all available devices and their current states
Set the target temperature for the thermostat (16-30°C)
Parameter descriptions lack constraint details. 'brightness' is described as 'Optional brightness level 0-100' but the constraint is buried in natural language rather than formalized as minValue/maxValue in schema. 'target_temperature' is described as 'must be between 16 and 30' in text only. LLMs cannot reliably parse these constraints without formal JSON Schema bounds.
No output schema documentation. Tools return unstructured strings (e.g. 'Living Room Light is now on at 70% brightness'). LLMs cannot predict output structure, extract data for downstream calls, or decide if information was successfully retrieved. Responses should be structured JSON with typed fields.
No error recovery guidance. Error messages are present ('Error: Brightness must be between 0 and 100') but do not tell the LLM what to do next. There is no pattern like 'Try set_temperature(18) to 20 degree Celsius' or indication whether the error is retryable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Sensitive operations (control_door_lock, set_temperature on thermostat) lack permission checks, audit logging, and tool annotations. No readOnlyHint/destructiveHint metadata to signal risk. A malicious LLM or prompt injection could unlock doors or set unsafe temperatures without any gating.
No idempotency or confirmation mechanism for irreversible operations. Calling control_door_lock('unlock') twice has side effects; an agent retry loop could unlock/lock the door multiple times. No dry-run or confirmation_required pattern.
Tool descriptions are brief (53 - 94 chars) and lack LLM-optimization. They state WHAT but not WHEN to use or dependencies. 'Control the living room light (on/off/toggle)' does not explain when to prefer control_light over activate_scene, or that activate_scene may override it.