Loading ToolBench
MCP Server for Home Assistant entity discovery and control via multi-provider LLM agents (LM Studio, Ollama, OpenAI, Gemini, etc.)
MCP Assist provides 10 tools with generally clear naming and descriptions, but exhibits significant gaps in schema completeness and parameter documentation. All tools have descriptions (positive), but many lack detailed input parameter descriptions and output schema documentation. The server handles Home Assistant integration well with appropriate risk classification (READ_ONLY vs WRITE), but parameter constraints are minimal and error handling guidance is absent from tool definitions.
Call a Home Assistant service with optional parameters
Get all Home Assistant areas with entity counts
Get all supported Home Assistant domains with entity counts and service information
Discover Home Assistant entities with optional filtering by domain, area, device_class, labels, or floor
Get detailed state and attributes for specific Home Assistant entities
Get historical state changes for Home Assistant entities
Get the smart system structure index for LLM entity discovery without full context dumps
Get the current state of a Home Assistant entity
Output schemas undocumented for all 10 tools. LLMs cannot determine what fields are returned, their types, or how to chain tool results. This violates pattern:tool and pattern:response-shaper. Example: get_domains says it returns 'domains with entity counts and service information' but structure is undefined.
Parameter constraints missing or minimal. Numeric parameters (hours in get_history, count in search) lack min/max bounds. Enum fields (domain in get_entities, service domain in call_service) are not declared as enums despite being select-list values. This invites hallucinated invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | 2024-11-05+ | v1 |
Get Home Assistant system information and installed components
Search the web using configured search provider (Brave or DuckDuckGo)
call_service 'data' parameter is type 'object' with no documentation of allowed keys or structure. LLMs cannot determine what fields to pass. This is a critical usability gap, forces LLMs to guess or requires multi-step discovery.
call_service is marked WRITE (destructive) but has no confirmation or dry-run pattern. An agent could turn off all lights without warning. pattern:confirmation-request should apply to all destructive service calls.
Error handling is absent from tool definitions. No error guidance documented. If an entity_id doesn't exist, what error is returned? How should LLMs recover? Missing pattern:recovery-guide implementation.
get_areas and get_domains are discovery tools but lack descriptions guiding LLMs on when to call them. Per pattern:tool-description, discovery tools should explain what they reveal and when to invoke them. Current descriptions are minimal.
Pagination not documented for tools returning multiple items (get_entities, get_history, search). No mention of limit parameters, offset/cursor, or total counts. LLMs may truncate results unaware of pagination requirements.