Loading ToolBench
MCP server for controlling smart home room illumination via a floor plan interface with real-time updates
The server provides 7 tools for smart home floor plan control with reasonable descriptions and clear naming. However, there are significant gaps in schema documentation, parameter descriptions, and error handling guidance. Tool names follow the verb_noun convention well (GetAllRooms, IlluminateRoom, etc.). Descriptions are present but vary in completeness. Input schemas are largely missing or inferred from C# attributes rather than explicitly documented. Output schemas are not documented at all. Error handling is minimal, tools return string responses without structured error categories or recovery guidance. The elicitation-aware ShowRoomPicker tool demonstrates thoughtful UX integration, but lacks formal schema documentation.
Turn off the light in a specific room.
Get the illumination status of all rooms in the floor plan.
Get the illumination status of a specific room.
Turn on the light in a specific room.
Show the Control Hub — an HTML UI for the smart home. Returns a self-contained UI resource with room cards and toggle buttons. The UI embeds current room state and lets the user toggle lights via the REST API. Prefer this over the elicitation panel for a richer visual experience.
Show the user an interactive button panel listing every room with its current light state. The user clicks a room to toggle its light on or off. Call this whenever the user asks to see room controls or wants to pick a room interactively.
Toggle the light state (on↔off) in a specific room.
Input schemas not formally documented in JSON Schema format. Parameters exist in C# code via attributes but are not declared as explicit JSON Schema objects with type, properties, required fields, and constraints. Tools like GetAllRooms (no params) and GetRoomStatus (roomKey: string) lack formal schema definitions accessible to MCP clients.
roomKey parameter lacks enum constraint. Description provides examples ('living-room', 'kitchen', 'bathroom', etc.) but does not declare them as an enum. Free-form strings invite hallucinated room keys (e.g., 'the-living-room' or 'Living Room') that will cause failures. Should enforce enum: ['living-room', 'kitchen', 'bathroom', 'master-bedroom', 'study-room', 'dining'].
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Output schemas not documented. Tools return plain strings ('Room "living-room" not found.', 'Light turned ON in Living Room.') without a declared output schema. LLMs cannot plan downstream actions or parse success vs. failure from unstructured text. Should return structured JSON objects with fields like { success: boolean, message: string, roomKey?: string, isIlluminated?: boolean }.
Error handling lacks recovery guidance. When a room is not found, tools return 'Room "X" not found.' with no suggestion for alternatives or recovery steps. Per pattern:recovery-guide, errors should guide the LLM: 'Room "kitchen-2" not found. Available rooms: kitchen, living-room, dining, ...' or 'Call GetAllRooms() to list valid room keys.'
No idempotent hints or destructive markers. Tools like IlluminateRoom and ExtinguishRoom modify state but are not annotated with destructiveHint=true or idempotentHint=true. The MCP spec supports tool annotations to declare intent, using them would clarify semantics for agents.
ShowRoomPicker and ShowControlHub descriptions are unclear about when to invoke them. Both provide interactive UX, ShowRoomPicker uses elicitation (legacy, per pattern:elicitation), ShowControlHub uses a resource URI with embedded HTML. Descriptions should clarify: call ShowRoomPicker for form-based selection, ShowControlHub for a rich visual dashboard. Currently, LLMs may pick the wrong one.
GetAllRooms returns multi-line string with no pagination support. If hundreds of rooms exist, the response could exceed token budgets. Should accept optional limit and offset parameters, and return structured JSON with total count and an array of room objects.
ShowControlHub returns HTML string, not a structured resource reference. The response should be a resource URI that clients can fetch separately, not embedded HTML embedded in the tool output. This prevents the HTML from consuming MCP message bandwidth and tool result token limits.