Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official
by homeassistant-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get HACS Info

ha_get_hacs_info
Read-onlyIdempotent

Search HACS repositories or fetch a repository's full details to inspect read-only Home Assistant Community Store data before dashboard setup or updates.

Instructions

Get HACS (Home Assistant Community Store) data — search the store or fetch repository details.

On Home Assistant 2026.11+ HACS is the built-in Marketplace; the tool uses whichever the instance has. Use action="search" to search/browse/list store repositories, or action="info" for one repository's full details as the store reports them (the README is in additional_info). This tool is read-only; to install or add repositories use ha_manage_hacs, and for non-HACS entities/config use the domain-specific tools.

DASHBOARD TIP: action="search", installed_only=True, category="lovelace" discovers installed custom cards to wire into ha_config_set_dashboard().

Examples:

  • Search the store: ha_get_hacs_info(action="search", query="mushroom", category="lovelace")

  • List installed: ha_get_hacs_info(action="search", installed_only=True)

  • Repository details: ha_get_hacs_info(action="info", repository_id="441028036")

  • Before an update: ha_get_hacs_info(action="info", repository_id="owner/repo", include_releases=True)

Caveats: info fetches full repository detail from GitHub, so it can hit GitHub rate limits without a connected GitHub account; search reads the locally cached repository index.

Input Schema

NameRequiredDescriptionDefault
queryNoSearch keyword (action='search')
actionYes'search' the store, or 'info' for one repository
offsetNoResults to skip for pagination (action='search')
categoryNoFilter by category (action='search'). One of the categories the store reports (search's store.categories); 'lovelace' means 'plugin' (dashboard cards).
max_resultsNoMaximum number of results (action='search')
repository_idNoNumeric HACS ID or 'owner/repo' path (action='info')
installed_onlyNoOnly return installed repositories (action='search')
include_releasesNoAdd the repository's GitHub releases and the release notes of versions newer than the installed one (action='info')

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv9.0.0
    • changedInput schema / properties / category / anyOf
      Previous value: -[
-  {
-    "enum": [
-      "integration",
-      "lovelace",
-      "theme",
-      "appdaemon",
-      "python_script"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / category / description
      Previous value: -"Filter by category (action='search')"New value: +"Filter by category (action='search'). One of the categories the store reports (search's store.categories); 'lovelace' means 'plugin' (dashboard cards)."
    • addedInput schema / properties / include_releases
      Added value: +{
+  "default": false,
+  "description": "Add the repository's GitHub releases and the release notes of versions newer than the installed one (action='info')",
+  "type": "boolean"
+}
  2. Changed3 schema fields changedv8.6.0
    • changedInput schema / properties / installed_only / description
      Previous value: -"Only return installed repositories (action='search', default: False)"New value: +"Only return installed repositories (action='search')"
    • changedInput schema / properties / max_results / description
      Previous value: -"Maximum number of results (action='search', default: 10, max: 100)"New value: +"Maximum number of results (action='search')"
    • changedInput schema / properties / offset / description
      Previous value: -"Results to skip for pagination (action='search', default: 0)"New value: +"Results to skip for pagination (action='search')"
  3. First observedv7.14.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, but the description adds genuinely new operational context: `info` hits GitHub and can be rate-limited without a connected account, while `search` reads a local cache, and the README arrives in `additional_info`. It does not discuss pagination limits or what an empty result looks like, keeping it short of a 5.

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?

The purpose statement is front-loaded, then caveats and examples are cleanly separated by bold headers. The examples partly restate what the schema's per-parameter descriptions already say, so the block is slightly longer than strictly needed.

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?

For an 8-parameter, two-action tool with an output schema (so return values needn't be described), the description covers mode selection, mutation alternative, rate-limit risk, and a workflow tip. An agent has everything required to call it correctly on the first attempt.

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; the description earns more by showing concrete parameter combinations in four worked examples (query+category, installed_only, repository_id in both numeric and owner/repo form, include_releases before an update). It does not add syntax or edge-case semantics beyond those examples.

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 first sentence names the specific verb and resource: retrieve HACS (Community Store) data with two modes, search or repository details. It explicitly contrasts with the sibling `ha_manage_hacs` (install/add) and with domain-specific tools, so an agent can distinguish it without opening the 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?

It states exactly when to use `action="search"` (browse/list) versus `action="info"` (one repo's full details), names the alternative tool for mutations, and adds a concrete routing tip for the dashboard-card case. No inference is left to the agent.

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