Skip to main content
Glama
Vortitron

home-assistant-mcp

by Vortitron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get system log (structured)

ha_get_system_log
Read-only

Retrieve deduplicated Home Assistant system log entries grouped by problem, so you can filter by severity, logger, or text and spot recurring errors without scanning raw lines.

Instructions

Home Assistant's deduplicated error store: one record per distinct problem, with level, logger, source file:line, occurrence count and first/last seen. Prefer this over ha_get_error_log — 20 grouped issues instead of 200 raw lines. Filter by minimum level, logger name or free text. Full tracebacks are omitted by default (you still get the final exception line); set include_exception=true, usually narrowed with 'contains', to read a whole stack.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum entries to return, newest first (default 25).
loggerNoCase-insensitive substring matched against the logger name only, e.g. 'hue'.
containsNoCase-insensitive substring matched against logger, message, source and traceback.
min_levelNoMinimum severity to include (default 'warning').
instance_idNoOptional: the instance you mean (as listed by vomehome_list_instances). When given, the call is refused if this session is targeting a different home, instead of answering from it.
include_exceptionNoInclude full tracebacks (default false — large).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only safety profile, but the description adds real behavioral detail: deduplication semantics, that tracebacks are omitted by default yet the final exception line is retained, and that include_exception returns full stacks. That default-vs-opt-in behavior is not derivable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, front-loaded with what the tool returns and its differentiator before the filtering and traceback guidance. No filler; every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the record shape (level, logger, source file:line, occurrence count, first/last seen). Annotations handle safety, so an agent has everything needed to call it and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine interaction tip not in the schema: pairing include_exception=true with 'contains' to narrow a stack read. It also summarizes the filter axes (min level, logger, free text), which reinforces rather than merely repeats the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('get system log') and characterizes the resource precisely as a 'deduplicated error store: one record per distinct problem' with the fields returned. It explicitly distinguishes itself from the sibling ha_get_error_log, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit preference rule ('Prefer this over ha_get_error_log — 20 grouped issues instead of 200 raw lines') and conditions for the include_exception toggle ('usually narrowed with contains'). When-to-use and the alternative are both named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools