Skip to main content
Glama

get_error_log

Retrieve and filter Home Assistant error logs by level, integration, or search term for targeted troubleshooting. Returns filtered log text with error and warning counts.

Instructions

Get the Home Assistant error log for troubleshooting.

All filters are optional and combine (AND semantics). Stats (error_count, warning_count, integration_mentions, total_lines) are computed over the filtered output so they match what's returned.

Args: level: Filter to lines containing this log level — ERROR, WARNING, INFO, or DEBUG. Case-insensitive. integration: Filter to lines mentioning this integration. Matches [name] or [homeassistant.components.name]. Case-insensitive. search_term: Case-insensitive substring filter applied per line. Useful for entity IDs, exception names, etc. lines: Return only the most recent N lines (applied after other filters). Useful when you only care about the tail.

Returns: A dictionary containing: - log_text: The (possibly filtered) error log text - error_count: Number of ERROR entries in the filtered output - warning_count: Number of WARNING entries in the filtered output - integration_mentions: Map of integration names to mention counts - total_lines: Number of lines in the filtered output - filters_applied: Map of which filter args were supplied - error: Error message if retrieval failed

Examples: get_error_log() # full log get_error_log(level="ERROR") # errors only get_error_log(integration="zwave_js") # one integration get_error_log(search_term="light.kitchen") # specific entity get_error_log(level="ERROR", lines=50) # last 50 errors

Best Practices: - Filter on the server side (here) rather than pulling the full log into Claude's context — saves tokens on noisy logs. - Combine integration + level="ERROR" to triage a single integration that's misbehaving. - Use lines to bound output when scanning a long-running HA.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
levelNo
integrationNo
search_termNo
linesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Since no annotations exist, the description fully describes behavior: filters combine with AND, stats are computed over filtered output, case-insensitive matching for level, integration, search_term. Return structure is detailed. No side effects mentioned but tool is read-only. Could mention error conditions more broadly.

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

Conciseness4/5

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

Well-structured with Args, Returns, Examples, Best Practices. Purpose is front-loaded. Slightly lengthy but all sections are informative and earn their place.

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?

Covers purpose, all parameters, return format, usage guidance, and examples. No gaps given the tool's complexity and presence of output schema in description.

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

Parameters5/5

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

Schema has 0% description coverage, so description provides all semantics: level specifies exact values, integration matching pattern, search_term as substring, lines for tail. Examples demonstrate usage. Completely compensates for schema lack.

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?

The description clearly states the tool retrieves the Home Assistant error log for troubleshooting. It specifies the action ('get') and resource ('error log') and distinguishes itself from sibling tools like get_entity or call_service_tool.

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

Usage Guidelines4/5

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

Best practices are provided, such as filtering server-side to save tokens and combining integration with level='ERROR'. The AND semantics of filters are explained. However, no explicit when-not-to-use or alternatives are mentioned.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/voska/hass-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server