Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official
by homeassistant-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

List Dashboard Resources

ha_config_list_dashboard_resources
Read-onlyIdempotent

List Lovelace dashboard resources such as custom cards, themes, and CSS/JS with pagination, unique IDs for updates or deletes, and inline content previews.

Instructions

List Lovelace dashboard resources (custom cards, themes, CSS/JS).

Returns one page of registered resources; total_count and has_more report the full set, and inline_count and by_type summarise every resource, not just this page. Each resource has a unique ID for update/delete operations. For inline resources (created with ha_config_set_dashboard_resource(content=...)), shows a preview of the content instead of the full encoded URL to save tokens. resource_mode is Core's lovelace resource mode; in 'yaml' mode resources cannot be created, updated or deleted through the API.

EXAMPLES:

  • Next page: ha_config_list_dashboard_resources(offset=100)

  • List with full content: ha_config_list_dashboard_resources(include_content=True)

Home Assistant 2026.6+ exposes resource management in the UI by default; API access works regardless of UI availability.

Input Schema

NameRequiredDescriptionDefault
limitNoMax resources to return per page
offsetNoNumber of resources to skip for pagination
include_contentNoInclude full decoded content for inline resources in the "_content" field. When False, a 150-char preview is shown instead. Rows past the per-response content budget carry '_content_truncated': True instead of '_content'; request a smaller page before copying content into an update.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv8.6.0
    • changedInput schema / properties / include_content / description
      Previous value: -"Include full decoded content for inline resources. Default False to save tokens (shows 150-char preview instead)."New value: +"Include full decoded content for inline resources in the \"_content\" field. When False, a 150-char preview is shown instead. Rows past the per-response content budget carry '_content_truncated': True instead of '_content'; request a smaller page before copying content into an update."
    • changedInput schema / properties / limit / description
      Previous value: -"Max resources to return per page (default: 100)"New value: +"Max resources to return per page"
    • changedInput schema / properties / offset / description
      Previous value: -"Number of resources to skip for pagination (default: 0)"New value: +"Number of resources to skip for pagination"
  2. First observedv7.14.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on real behavior: pagination semantics, that total_count/inline_count/by_type describe the whole set rather than the page, that inline content is previewed to save tokens, and that the yaml mode blocks writes. It does not mention permission or auth requirements, which is the main remaining gap.

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?

Purpose and paging semantics are front-loaded and the examples are compact and actionable. The closing note about Home Assistant 2026.6+ UI availability is tangential to calling the tool and is the one sentence that does not fully earn its 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?

An output schema exists, yet the description still clarifies which return fields summarize the full set versus the page — exactly the ambiguity that would otherwise cause misreading. Combined with the yaml-mode caveat and the content-preview rule, an agent has everything needed to page and to fetch content safely.

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 meaning beyond the schema by showing offset used for paging and by tying include_content to the tradeoff between token cost and getting full content before an update. The truncation/budget caveat is largely restated from 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?

Opens with a specific verb and resource ("List Lovelace dashboard resources") and immediately enumerates what counts as a resource (custom cards, themes, CSS/JS). This distinguishes it cleanly from the sibling write tools ha_config_set_dashboard_resource and ha_config_delete_dashboard_resource.

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?

Gives concrete invocation scenarios (next page via offset, full content via include_content) and names a hard usage constraint: in 'yaml' resource mode nothing can be created, updated, or deleted through the API. It references the creating sibling (ha_config_set_dashboard_resource) but never explicitly routes the agent to it for writes, so the alternative-selection guidance is implied rather than stated.

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